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Please replace entire specification with the following amended specification: 
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S IP Ba s ed Distributed Virti »l-SAN 

By 

Sh o ng (Ted) Tai Tsao 

8 /1/2002 

10 

Field of the Inv eirtieft 

This inv e ntion is th e continuation of the pr e vious inv e ntion, application numb e r 
60/^01,23 8 , of ''Concurrent Wob based Multi Task Support for Control Manag e m e nt 
Syst e m'', which focus on w e b bas e d multi - tasking support for w e b consol e in th e c e ntral 

15 controll e d distribut e d scalabl e virtual machine e nvironm e nt. The pr e sent inv e ntion focus on 
distributed IP SAN bas e d storage service and other distribut e d s e rvic e s in th e c e ntral 
controll e d distribut e d scalable vutual machin e environm e nt. It r e lat e s gen e rally to IP based 
out band acc e ss e d distribut e d virtual SAN infrastructur e , its automatic configuration, its 
storag e volumes allocation and acc e ssing s e rvic e s. This inv e ntion also presents th e 

20 applicability of th e principl e s of IP bas e d distribut e d virtual SAN servic e to oth e r servic e s 
and applications in a similar environm e nt . 
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FIELD OF THE INVENTION 

The present invention generally relates to computer communications network. More 
specifically, the present invention relates to web based data storage systems. 

5 

BACKGROUND OF THE INVENTION 

Baekground Information 

a) T e rminology: 

CCDSVM: 

10 It is an abbr e viation for central controll e d distribut e d scalabl e virtual machine syst e m. 

Th e CCDSVM allows a control manag e m e nt station to control a group of syst e ms and 
provid e distribut e d s e rvic e s to cli e nt sy s t e m in Intran e t and Intern e t as w e ll as in LAN 
e nvironment. 

Storage Media: 

15 Storag e m e dia includ e s magn e tic hard disk driv e s, solid stat e disk, optical storage 

driv e , and m e mory card e tc. 

Storage Connection ond Control Media: 

Storag e conn e ction and control m e dia includ e s controll e r of IDE, SCSI, Fibre optical, 
Ethernet, USB, or may be wir e l e ss m e dia and all r e lated cabl e s e tc. Each controller of storag e 
20 m e dia such as Raid, IDE, or SCSI controll e r may control multipl e storage media driv e s on a 
syst e m. 

Storage Syst e m: 
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Storag e sy s t e m includ e s one or mor e storag e m e dia and th e storag e conn e ction and 
control m e dia. Storag e sy s t e m also contains roiatod softwar e modul e s to d e liv e r storag e 
s e rvic e s. 

5 SAN stands for storag e ar e a of network. It is a storage system, which provid e s 

comput e r host with block data s e rvic e through storag e connection m e dia, such as Fibr e 
optical cable, Eth e rn e t cabl e or oth e r m e dia by using protocol bas e d on DP, non IP bas e d such 
as Fibr e Chann e l, or oth e rs. IP SAN us e s IP based protocol to provid e storag e raw block data 
s e rvices. All discussion of SAN in this inv e ntion ar e within th e scope of a mod e l of c e ntral 
10 controll e d distribut e d scalabl e virtual machin e (CCDSVM). 

SNSf 

It stands for domain nam e se rv e r of n e twork t e chnology, which is a Int e rnet softwar e 
infirastructur e . It helps any s yst e m on th e n e t to find its pe e r targ e t syst e m's n e twork address 
in ord e r to s e nd th e m e ssag e to its pe e r syst e m. 

15 smB^ 

An abbr e viation for ''Simpl e Network Manag e m e nt Protocol'', which is a standard 
Intern e t protocol. The SNMP tmp is a UDP packet sent by SNMP daemon on a SNMP agent 
s yst e m to SNMP n e twork manag e m e nt station through network link. 

20 Figwe»f 

1) Distribut e d Virtual SAN Infi-astmcture. 

2) Th e Actual Components of Distributed Virtual SAN. 

3) Virtual SAN Automatic Configuration Protocol. 

■ 4 ) Virtual SAN Auto Configuration Protocol Pack e t format. 
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5) Exampl e of Storag e Volume Information of an IP SAN Unit. 

6) A Hypothetical Exampl e of Storage Volume R e quests and Assignment. 

7) Dir e ct Attached Storag e Syst e m. 

8) In Bound Access e d Virtual Storag e Syst e m. 

5 9) A Simplifi e d Diagram of C e ntral Controll e d Distributed Scalable Virtual Machin e 

Syst e m. 

10) A Simplified Diagram of Disaster Recov e ry Scheme of Distribut e d Virtual SAN 
Infrastructur e . 

10 In the drawing, lilc e e l e ments ar e d e signed by lik e r e f e r e nc e numb e rs. 

Brief D e scription of th e Invention 

Today's corporate IT professional s typically face [[faces]] many challenges to handle 
the ever increasing information and data. This oft e n requires many To handle large amount 
of data, many organizations [[to]] expand their storage capacit y bv employing r[ J1 manage 

1 5 storage systems locally in order to maintaining their and to k ee p th e normal business [[run]] 
operating . A conventional approach is to use Curr e ntly, Th e IP based network attached 
storage ("N AS "'), which (network attach e d storag e ) effectively provides data storage and 
services for end users 's fil e system n ee ds . Moreover, On the oth e r hand, at the enterprise 
level, the majority storage systems are still s e rv e r directly attache d or connected to serverfs) 

20 or host(s) as shown in Figure 7. These server(s) and/or host(s) are typically used - ffter^ 
and b e ing acc e ss e d as raw block data devices through conventional commimication 
connection media, such as [[either]] traditional IDE, SCSI, Fibre Channel, or [[may be]] 
Ethemet. 
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The serve r, which is directly [[direct]] attached to a storage system as illustrated in 
FIG. 7 typically (Fog. 7) has many drawbacks, which are described as follo wing : 

a) Curr e ntly, th e most advanc e a typical conventional storage management system is 
only capabl e of handling t o handl e 4TB (terabytes) of data, which is far from usually not 

5 good enough for a typical enterprise storage management system: r e quirem e nt. 

b) The most of serve rs, which are directly attached to^storage systems, have [Fh asll 
problems for further expanding their storage t o e xpand its capacity. For example, fa -seme 
ease? it may require to purchase new servers is quit e often to r e quir e purchasing a n e w s e rv e r 
in order to increase e xpand th e storage capacity: . In oth e r cas e s, it also r e quires to shutdown 

10 th e s e rv e r and to stop th e normal op e ration in ord e r to e xpand the storage capacity. 

c) The storage being attached to a server can only be accessed by the attached server 
and can not be shared by othe r servers even if [[all server's storage availability is not evenly 
distributed across all servers within h as spare capacity left whil e oth e r s e rver are in shortag e 
of the s torage capacity within a d e partm e nt or cross department m a organiz;ation[[.]]; 

15 d) Each attached storage system has to be managed separately and this is a 

nightmare for IT professionals;[[.]] 

e) With the attached storage system, the backup/restore has to go through the data 
network, this will tax or reduce t he [[data]] network performance;[[.]] 

f) [[The]] a typical SCSI connection only allows a_122meter distance for data 

20 accessing with 15 storage devices . Similarly, [[while]] Fibre Chaimel is [[also]] limited to 10 
kilometers communication distance long. Distance limitation [[This]] effectively prevents 
them from being the best choice for disaster recovery of the storage system[[.]] : and 

g) The Fibre Channel based storage system caimot handle well for the 
interoperability. Also, Fibre Channel based storage system is expensive to build and to 

25 maintain. 
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Figure 8 shows ft CTe4s a conventional type of virtual SAN, which is in-band 
controlled and accessed (Fig, 8 ), w ith which the data path from hosts (1 of Fig. 8) to the SAN 
units (4 of Fig. 8) going rFgoesll through virtual SAN control management station (2 of Fig. 
8). It is not efficient in term of accessing the data by the hosts because d ue4e the virtual 
5 SAN control management station can easily be a performance bottleneck. Similarly B y sam e 
r e ason , the scalability of this type of virtual SAN [[also]] is poor. 



SUMMARY 

With [[the]] rapid development of high speed communication technology, the 
10 problems mentioned above can be solved by an IP based out-band accessed distributed 

virtual SAN infrastructure (Fig. 1) of this invention. With this invention, each host[[s]] (1 of 
fig. 1) can directly access IP based SAN units (4 of Fig. 1) without going through control 
management station (3 of Fig. 1). The IP based out-band accessed distributed virtual SAN 
infrastructure (Fig. 1) actually represents an example of central controlled distributed 
15 scalable virtual machine system (CCDSVM) (Fig. 9). Wherein, each system units actually is 
a SAN unit (4 of Fig. 1), specifically is an IP based SAN unit. 

With this invention, each SAN unit (4 of Fig. 1) can be accessed by one or more hosts 
(1 of Fig.l) and each host[[s]] can access one or more SAN units (Fig. 6). In addition, the 
storage accessing goes directly through communication link (2 of Fig. 1) between hosts (1 of 

20 Fig. 1) and SAN imits (4 of Fig. 1) without involvement of the control management station (3 
of Fig. 1). Further, the SAN units (4 of Fig. 1) can be dynamically added without 
interrupting normal data accessing from hosts (1 of Fig. 1) and [[they]] are controlled, 
monitored, and managed by a.control management station (3 of Fig. 1) through a 
management console (10 of Fig. 1). The control management station (3 of Fig. 1) may also 

25 accept storage volume/partition requests from each host[[s]] (1 of Fig. 1), and assign the 
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matched volumes/partitions of SAN units (4 of Fig. 1) to these hosts. Therefore, each 
host[[s]] (1 of Fig. 1) could directly access the right volumes/partitions of assigned SAN 
units without [[goes]] going through the control management station again. 

This invention will become understood with reference to the following description, 
5 claims, and accompanying figures. 

BRffiF DESCRIPTION OF THE DRAWINGS 

The present invention will be understood more fully from the detailed description 
given below and from the accompanying drawings of various embodiments of the invention, 
10 which, however, should not be taken to limit the invention to the specific embodiments, but 
are for explanation and understanding only. 

Figure 1 illustrates a distributed virtual storage area of network ("SAN") 
infiBstructure in accordance with one embodiment of the present invention: 

Figure 2 illustrates actual Components of Distributed Virtual SAN in accordance with 
15 one embodiment of the present invention: 

Figure 3 illustrates Virtual SAN Automatic Configuration Protocol in accordance 
with one embodiment of the present invention: 

Figure 4 illustrates a Virtual SAN Auto Configuration Protocol Packet format in 
accordance with one embodhnent of the present invention: 

20 Figure 5 illustrates an Example of Storage Volume Information of an IP SAN Unit in 

accordance with one embodiment of the present invention: 
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Figure 6 illustrates a hypothetical example of Storage Volume Requests and 
Assigmnent in accordance with one embodiment of the present invention: 

Figure 7 is a conventional Direct Attached Storage System: 

Figure 8 is an In-Bound Accessed Virtual Storage System: 

5 Figure 9 illustrates a Simplified Diagram of Central Controlled Distributed Scalable 

Virtual Machine System in accordance with one embodiment of the present invention: and 

Figure 10 illustrates a Simplified Diagram of Disaster Recovery Scheme of 
Distributed Virtual SAN Infi-astructure in accordance with one embodiment of the present 
invention. 

10 

DETAILED DESCRIPTION Description of Drow iags 

The following terms are used through out this patent application to describe the 
present invention. A central controlled distributed scalable virtual machine (''CCDSVM") 

15 system allows a control management station to control a group of systems and to provide 
distributed services to client systems over the Intranet. Internet and/or LAN environment. 
Storage media includes magnetic hard disk drives, solid state disk, optical storage drive, and 
memory card etc. Storage connection and control media may include controller of IDE, 
SCSL Fibre optical Ethernet USB, or wireless media, and/or other related cables etc. Each 

20 controller of storage media such as Raid, IDE, or SCSI controller may control multiple 
storage media drivers on a system. Storage system includes one or more storage media 
devices, storage connections, and/or storage media controllers. Storage system also contains 
related software modules for delivering storage services. 
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Storage area network C'SAN") is a storage system that is capable of providing block 
data services to various computer hosts through storage connection media such as Fibre- 
optical cable. Ethernet cable or Internet Protocol C'W) based connection media protocol or 
non-IP based connection media protocol The non-IP based connection media protocol m 
5 one example, includes Fibre-Channel IP SAN uses IP based protocol to provide storage raw 
block data services. All discussions of SAN in this invention are within the scope of a model 
of central controlled distributed scalable virtual machine ("CCDSVM"). 

DNS stands for domain name server of network technology. DNS is an Intemet 
software infrastructure and is capable of identifying network addresses for its peer systems. 
10 For example, the network addresses may be used to communicate with the peer systems. A 
Simple Network Management Protocol ("SNMP") is a standard Intemet protocol A SNMP 
trap is a user datagram protocol ("UDP'') packet which may be used to send the SNMP 
daemon on a SNMP agent system to a SNMP network management station via network links. 

Fig. Shows]] shows an example of a^sunplified block diagram of IP based out- 
1 5 band accessed distributed virtual SAN infrastructur e. The distributed virtual SAN 

infrastructure . which includes multiple hosts (W network infrastructures (2\ a control 
management station (3\ virtual storage pool (11) having multiple IP SAN units, and a 
management console (10). In one embodiment, each host (1): 

ft) Hosts (1): 

20 It-contains service software modules (9 of Fig. 1) . The service software modules (9) 

are configured to communicate with a control management software module (7) of_a control 
management station (3) for storing to g e t storag e infomiation on a specific IP SAN unit (4). 
It also communicates with service software modules (6) of IP SAN unit (4) to retrieve a 
[[get]] block of data from SAN imits (4 of Fig. 1 ). The service software modules (9) can be 

25 coded or unplemented with any suitable programmmg languages such as C, C-H-, Java or 
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Others . The service software modules (9) may also and can u se any suitable protocols such 
as IP based or non-IP based or other protocols. 

The host (I), in one embodiment could be any syst e m such as a server, a.desktop, 
[[or]] a laptop PC, etc., which needs to access a_block data storage. The spare host (12 ef 
5 Fig. 1) represents a part of recovery scheme that could be implemented in a^CCDSVM 
environment. 

b) Network infra s trueture (2): 

It r e pr e s e nts Network infrastructure (2) can be any kind of communication links, 
which could be [[either]] a department LAN, a^corporate intranet, an Internet infrastructure 

10 or others. In one embodiment, network infrastructure (2) includes It consists switches, 
routers, gateways, cables (Ethernet, optical Fibre, and oth e rs) , wireless communication 
media, or others. The network infrastructure (2) provides data path between hosts (1), 
distribute control management station (3), and SAN Units (4). The network infrastructure (2} 
also mcludes software mfi^structure such as DNS or DHCP or oth e rs to for facilitating be^ 

15 eaeh-systems on the net to identifying find-fee target address es, which are used for sending or 
receiving data within a network domain or in a cross-domai n network environment. 

To simpli^ th e discussion, wh e n d e scribing se nd a m e ssag e from a syst e m A to a 
system B, it will simply impli e d that th e It should be noted that DNS and/or other Intemet 
address identification mechanism may be used when a message or data stream is sent from a 
20 system A to a system Bi s-used. In addition, the messag e is sent is send from source system A 
to target system B via communication link of this network infrastructure. 

€) Control management s tation (3): 

It Control management station (3) includes distributing control management software 
modules (7) and console support software modules (8). To support web-based console, it 
25 must hav e requires the w eb server software (15). The distribute control management 
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software modules (7) communicate with service modules (6) of IP SAN units (4) to retrieve 
[[get]] storage information for constructing a virtual SAN storage pool (1 1) . The 
communication between distributed control management software modules (7) and service 
modules (6) of IP SAN units (4) is fiirther configured rfJl] to monitor IP SAN unit, and to 
5 perform various system operations, which include[[s]] storage configuration and partitioning 
etc. The control management software modules (7) [[It]] also communicates with service 
software modules (9) of host (1) for distributing storage volumes to each hosts (1). The 
distribute control management software modules (7) can be implemented with any suitable 
programming languages such as C, C-H-, Java, XML^ etc. The communication protocols used 
1 0 by distribut e control manag e m e nt softwar e ,(7) between control management station (3) and 
IP SAN units (4) could be any suitable IP based protocols. The communication between 
control management station (3) and hosts (1) can be any suitable IP base or non-EP based er 
edi«=-protocols. 

The console support software modules (8) employ inter-process communication 
15 mechanism to obtain [[get]] information relating to IP SAN units (4) fi-om the 

distributed control management software modules (7 ) through int e r proc e ss conmiunicat e 
m e chanism . The console support software modules (8) [[It]] fiirther provide[[s these]] 
information to web server software (15) through the inter-process communication 
mechanism. The console support software modules (8) can be implemented with any 
20 suitable programming languages such as C, C++, Java, XML^ etc. 

The web server software (15) communicates with management console software (10) 
on console host (14) through web protocol such as HTT P. The web server software (15Us 
configured to provide e nd user a^centralized storage manajgement capability withm the [[for]] 
entire distributed virtual SAN infi^structur e for anv end user over a network . The web server 
25 software (15) could be an existing commercial ly available software or other proprietary 
software. 
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To simplify foregoing discussion, the communication path mentioned above will be 
simply referred to_as console support software modules (8 ), which communicate 
(send/receive) with management console (10) on console host (14) (without further 
mentioning the role and function of web server software (15) on control management 
5 station). 

In addition, to support non-web based console, there is no n ee ds of web server 
software (15) on control management station (3) is often not required . In this case, the 
console support software modules (8) could communicate with management console 
software (10) with a suitable protocol other than a,web protocol such as HTTP. 

10 d) IP SAN Units ( 4 ) and Virtual Storage Pool (11) 

The virtual storage pool (11) includes multiple IP SAN units (4), wherein each IP 
SAN unit further includes service modules (6). The IP SAN units (4) further containrfsll 
storage media, storage communications and control media. The storage hardware media of 
each IP SAN unit (4) is might b e configured [[in]]to_have one or more logical volumes . Each 

1 5 and each volume , in one embodiment, is further partitioned into several portions, as shown in 
Fig ^ might has several partitions (Fig. 5) . The IP SAN unit (4) further [[also]] contains 
block data services and other service software modules (6 \ The service software module (6) 
is configured to , which can communicate with distribute control management station (3) for 
providing t o provid e storage information and for performing p e rform storage operations. 

20 The service software modules (6) , in another embodiment, are further configured to 

communicate also communicates with service software modules (9) of hosts (1) for providing 
to provid e block data services for the host (1). The service software modules (6) can be 
implemented [[with]] by any suitable programming languages such as C, C-H-, Java, etc and 
the v may employ any suitable IP based communication protocols for data transfe r used by 

25 s e rvic e software modul e s (6) can b e any suitabl e IP bas e d protocol . 
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In one embodiment, the control management station (3) and organizes rfMultipleU IP 
SAN units (4) to form the are organized and formed a virtual storage pool (1 l) by control 
manag e ment station (3) in this invention > The virtual storage pool (ll) may contain 
information relating to of each IP SAN unit's IP addresses, the storage volumes of the block 
5 data, their addresses and sizes etc from of each IP SAN unit_(4}[[s]]. [[The]]A spare BP SAN 
unit (13 of Fig. 1 ) represents a.part of recovery scheme used in the central controlled 
distributed scalable virtual machine environment. 

e) Fibre Chonncl to IP Gateway (5): 

10 [[It]] Fibre channel to IP gateway (5) is a component that is configured to provide 

translatio n translat e s between Fibre Channel based protocol and IP based protocol so that 
Fibre Channel based SAN unit will appear[[s]] as if IP based SAN unit to the rest of the 
world (Fig. 1). 

^ Fibre Channel Si\N Unit (6): 

1 5 Fibre channel SAN unit is similar rrSimilarll to an IP SAN unit (4) except it uses 

Fibre Channel storage contro l which and connection m e dia and it uses Fibre Channel 
protocol to conununicate with other p arties over the network . In addition, Fibre Channel 
SAN unit^ (6 of Fig. 2) will appears as an IP based SAN unit to [[this]] fee distributed 
virtual SAN once it connects to a Fibre Channel to BP gateway (5 of Fig.2). Therefore, to 

20 simplify th e foregoing discussion, a fibre channel SAN unit riitll will be treated [[same]] 
similarly as an IP SAN unit in all of following discussion without additional comments. 

^ Manogcmcnt Con s ol e (10): 

The management console on console host (14), which has been described in pending 
patent of "Concurrent Web Based MultUTask Support for Control Management System'' by 
25 the same author. mtH The management console could be a commercial ly available web 
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browser or a proprietary Web browse r. A web browser r ^vbieb is able to communicate with 
web server software (15) on control management station (3) through a.web protocol such as 
HTTP. The Web browser could be implemented b3;_[[with]] any suitable programming 
languages such as C, C-H-, Java, XML^ etc. In addition, the management console software 
5 module (10) could be a networked software modul e and/or oth e r than a web browser 

software . In this case, any other suitable network protocols can be used instead of using web 
protocol such as HTTP. All of th e s e hav e b ee n m e ntion e d in section c) abov e . 

To simplify the foregoing discussion, the communication path between management 
console (10) on console host (14) and the console support software modules (8) on control 
10 management station (3) will not fiuther mention the role or fimction of web server software 
module (15) in this invention. 

From management console (10), muhiple concurrent system operations and tasks can 
be performed for th^entire distributed virtual SAN infrastructure. There are may be one or 
more management consoles of distributed virtual SAN infi-astructure anywhere on the net. 

1 5 Fig. 2 :This figur e is illustrates a portion of Fig. 1 relating to an . It r e pres e nts th e 

actual virtual SAN. The multiple SAN units form[[s]] a virtual Storage pool (11). The 
virtual storage pool (\\) may contain mformation of each IP SAN unit's TP address, the 
storage volumes and their sizes^ etc. 

Fig. 3 : This diagram shows a protocol of virtual SAN automatic configuration and 
20 building as well as shutting down a virtual SAN shutdown . The packet format used with this 
protocol is described in Fig. 4. 

Fig. 4 : This Diagram shows the message format, which is_used by "Virtual SAN 
Automatic Configuration Protocol" for sending and receiving a packet. 

Fig. 5 : This Fig. Shows the storag e illustrates a storage layout in an IP SAN unit, 
25 wherein the storage lavout f (whichll may be fiirther divided into multiple volumes and each 
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volume may be further divided into multiple partitions. Each [[The]] volume refers to a 
logical storage imit in this discussion and it might contain muhiple pieces of storage space 
from multiple storage hardvy^are media. 

Fig. 6; This figur e actually is a simplified and a portion of Fig. 1, which shows a 
5 hypothetical example of how hosts are configured to access the Storage Volume of IP SAN 
units can b e ing acc e ssed by hosts . Where each IP SAN unit is a portion u nits ar e portion of 
virtual storage pool (1 1 of Fig. 2) and eac h host is substantiallv the hosts ar e thos e same as 
presented in Fig. 1. 

Fig, 7: Th e Dir e ct Attach e d Storag e Syst e m. 

10 Fig. 8[[:]] is a block diagram illustrating an I n-Band Accessed Virtual SAN. Fig. 8 

This Figur e shows another type of virtual SAN, wherein, the actual storage data path from 
hosts to IP SAN imits has to go through control management station. 

Fig. 9[[: A]] isa, Simplified Diagram of Central Controlled Distributed Scalable 
Virtual Machine and ref e rr e d as CCDSVM for bri e f With this invention, the systems in a 
15 CCDSVM can be flexibly organized into multiple different service pools according to their 
fimctionalities[[y]]. For example, multiple IP SAN units can form a virtual SAN storage 
pool. The hosts of CCDSVM could form other service pools to provide services other than 
storage services such as video services, security monitor services, and all other services 
provided on Web (or nef) and on net etc . 

20 Fig.lO[[: A]] is a SimpHfied Diagram of Disaster Recovery Scheme of Distributed 

Virtual SAN Infrastructure, which includes e ^sists one virtual storage pool of multiple IP 
SAN units and one service pool of multiple hosts. For example. It assum e s that host 1 
accesses IP SAN units 1 and 2 while host 3 accesses IP SAN units 4 and 5. Also> It also 
assum e s that IP SAN unit 1 and 2 are mirrored so that they have kept the same copy of data 
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for host L The same to be trae for IP SAN unit 4 and 5 with host 3. In addition, it assum e s 
#iat-IP SAN unit 3 may be [[is]] a spare unit and the host 2 could be rrisH a spare host. 

'■ Detailed Description of the Inv e ntion 

5 

— 1: Distributed Virtual SAN Infra s tructure; 

Fig, 1 [[Shows]] shows a simplified diagram of a distributed virtual SAN 
infrastructure according to [[this]]Ae present mvention. With [[this]] the distributed virtual 
SAN infrastructure, the distributed virtual SAN storage pool (1 1 of Fig. 1) comprises one or 
10 more SAN units (4 of Fig. 1 ), which may be further connected to a distribute control 

management station (3 of Fig. 1) . The SAN units (4) [[and]] can be accessed by one or more 
hosts (1 of Fig. 1) via network infrastructure (2 of Fig. 1) . The entire distributed virtual SAN 
infrastructure can be operated through management console (10 of Fig. 1 ). 

Virtual Storage Pool Auto Building and Initioting: 

1 5 The virtual storage volume pool (1 1 of Fig. 1) of the distributed virtual SAN 

infrastructure (Fig. 1) can be initiated and updated when eac h of the IP SAN units (4 of Fig. 
4-) is_ b e ing booted and brought to online . The virtual storage volume pool (1 1) , in one 
embodiment is and can b e updated when at least one of [[each]] IP SAN unit[[s]] is powered 
down or removed from the web environmen t bemg shutdown . fte-Fig. 3 shows the 

20 distributed Virtual SAN Automatic Configuration Protocol, which leads to the success of 
constructing the virtual storage pool (1 1 of Fig. 1 ) of distributed virtual SAN infrastructure 
(Fig. 1) according to this invention. The following steps have described the automatic 
building sequence of storage volume pool of the virtual SAN based on this protocol (Fig. 3). 
The protocol described bellow could be IP based protocol such as SNMP, or a much simple 

25 UDP protocol (Fig. 4), or any other suitable protocols. 
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a) When any of IP SAN unit (4 of Fig. 1) such as unit (n) brought up [[to]] onHne, 
[[its]] SAN service modules (6 of Fig. 2) of the IP SAN unit (4) sends rFsent]] out a "SAN 
unit (n) startup" packet , as illustrated in Fig. 4, (Fig. ^) t o distribute control management 
station (3 of Fig. 1). The "SAN unit (n) startup" packet This m e ssag e could be a simple user 

5 defined UDP packet (Fig. 4) indicating a system just being powered up w ith m e ssage typ e of 
s yst e m up . [[This]] The m essage carried by the packet could also [[could]] be a SNMP trap 
of cold start packet, or link-up packet (4 of Fig. 1) or other short packet/message of any 
suitable IP protocols. 

When distribute control management modules (7 of Fig. 1) of distribute control 
10 management station (3 of Fig. 1) receives IP SAN unit (n)'s message, it stores the IP SAN 
unit (n)'s information. 

b) After storing information of the IP SAN unit, the control management modules (7 
of Fig. 1) on distribute control management station (3 of Fig, 1) sends back a "need SAN unit 
(n)'s storage info" packet to IP SAN unit (n) (4 of Fig. 1). 

15 e) When SAN service modules (6 of Fig. 1) on IP SAN unit (n) (4 of Fig. 1) 

receivefrd]] the p acket of "need SAN unit (n)'s storage info", it g e ts they obtam the storage 
information on the IP SAN unit (n) (4 of Fig. 1), which may include [Fincludesll the number 
of storage volumes, each volume's start ing address (logical block address, LB A), length, and 
the end address (logical block address, LBA). The SAN service modules (6 of Fig. 1) then 

20 send back a packet of "xmit (n) storage info", which may include [[includes]] all information 
obtained [[to]] from the control management station (3 of Fig. 1). 

d) After receiving the "unit (n) storage info" packet from IP SAN unit (n) (4 of Fig. 
1), the distribute control management modules (7 of Fig. 1) on distribute control 
management station (3 of Fig. 1) update[[s its]]tite stored information of virtual storage pool 
25 (1 1 of Fig. 1) with corresponding storage information of IP SAN unit (n) from packet. 
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e) When an y one of IP SAN unit (n) is.shutting down, the service module (6 of Fig. 
1) of the IP SAN unit (n) (4 of Fig. 1) sends a_"Unit (n) shutdown" message t o the distribute 
control management station (3 of Fig. 1). This shutdown message could be an SNMP trap of 
link down, or a [[much]] simple UDP packet (Fig. 4) with message type of system down, or 
5 other short packet based on some other protocols. 

^ After r e c e iv e d receipt of the " unit (n) shutdown" packet from IP SAN imit (n) (4 
of Fig. 1), the distribute control management modules (7 of fig. 1) on distribute control 
management station (3 of Fig. 1) update[[s]] information of the virtual storage pool (11 of 
Fig. l \ which is [[that]] specific [[for]]tothe IP SAN unit (n) (4 of Fig. 1). 

10 Distributing Storag e Volume s in Pool for Ho s ts Accessing: 

After one or more IP SAN units (4 of Fig. 1) are brought into online, the control 
management station (3 of Fig. 1) obtains and/or stores has own e d information [|"of|1 relating to 
storage volumes and networking protocols for [[all]] everv IP SAN unit (4 of Fig. 1) in the 
virtual storage pool (11 of Fig. 1). Therefore, the control management station (3 of Fig. 1) is 
15 able to distributed [[distributing]] storage volumes to hosts (1 of Fig. 1) in several steps. 

For example. F irst, the host 1(1 of Fig. 1) sends j[ request to control management 
station (3 of Fig. 1) requesting a storage space , such as [[needs]] 80 GB (gigabyte) of storage. 
Second, the control management station (3 of Fig. 1) stores host 1 information and searches 
for availability of 80 GB of storage volume. The control management station (3), for 

20 example, fmds an 80 GB available storage volume in I t found the volume 2 [[on]] of the IP 
SAN unit M (Fig. 6). Third, the control management station (3 of Fig. 1) sends the requested 
information of host 1 to IP SAN unit M (Fig. 6), wherem the requested information [[which]] 
includes the IP address of host ![[.]] and the requested storage size. The control management 
station (3 of Fig. 1) also sends the storage volume information [[of]] relating to the IP SAN 

25 unit M to host 1 (1 of Fig.l), wherein the storage volume information [[which]] includes the 
IP address of EP SAN unit M, the volume number and the size, the volume's starting address. 
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and volume's ending logical address block (LB A) [[etc]]. Therefore, all parties of three^ 
namely the control management station (3) and host 1 and the IP SAN unit M, keep the same 
storage volume assignment information [[in sync]]. Fourth, once the host 1 (1 of Fig. 1 ) and 
IP SAN unit M (Fig. 6) get each other's information, the host (1 of Fig. 1) can directly and 
5 independently access the volume 2 on IP SAN unit M immediately and the right way with 
r e sp e ct of s e curity ch e cking by IP SAN unit M . in one embodiment, is further configured to 
perform security checking in light of storage accessing . 

Alternatively, The[[se]] above described steps may also be semi-automatically setup 
with assisting of system operations performed by the [[from]] management console (10 of 

10 Fig. 1). For example, [[first]] an administrator could initially setup volume 2 of IP SAN unit 
M (Fig. 6) to be exclusively accessed by host 1 (1 of Fig. 1) as long as [[he]]_ttie 
administrator acknowledges that host 1 needs such size of storage volume. S e cond, th e The 
administrator can also [[can]] setup the host 1 with all information needed to access volume 2 
of IP SAN unit M (Fig. 6). Finally, the host 1 (1 of Fig. 1) can access volume 2 of IP SAN 

15 unit M (Fig. 6) directly without [[goes]] going through the control management station (3 of 
Fig. 1). 

Dynamic Capacity Expanding; 

The present invention also discloses a mechanism of dynamically expanding storage 
capacity. A fter the distributed virtual SAN storage pool (1 1 of Fig.l)is initiated, the host (1 

20 of Fig. 1) will be able to access the volume of an on assign e d IP SAN unit (4 of Fig. 1) in the 
pool (1 1 of Fig. 1) directly without further involvement of the control management stations^ 
mvolvement (3 of Fig. 1). This will allow the storage pool (1 1 of Fig. 1) of this distributed 
virtual SAN infi^tructure (Fig. 1) to continue expanding without affecting [[effect]] any 
hosts (1 of Fig. 1) to continue accessing the storage volumes on assigned IP SAN units (4 of 

25 Fig. 1) in the pool. As a result, this guarantees that the distributed virtual SAN storage pool 
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(1 1 of Fig. 2) can be dynamically expanded without interrupting any normal storage 
operations and accessing of entire distributed virtual SAN storage pool (1 1 of Fig. 2). 

Sealability: 

The present invention further discloses a technique of system scalability. Once the 
5 distributed virtual SAN storage pool (1 1 of Fig. 1) [[being]] js constructed, each host[[s]] (1 
of Fig. 1) can access one or more IP SAN units (4 of Fig. 1) in the storage pool (1 1 of Fig. 1) 
of the distributed virtual SAN infrastructure (Fig. 1) whenever it requests[[ed]]. For 
example, host 1 (Fig. 6) can access IP SAN unit 1, unit 2, and unit M (Fig. 6) after the host 
(1) requests an access to the IP SAN units and subsequently, the it r e qu e st e d and grant e d by 

10 control management station (3 of Fig. 1) grants the request This effectively provides 
scalable storage system for each hosts (1 of Fig. 1) within distributed virtual SAN 
infrastructure (Fig. 1) of this invention. Further, the distributed virtual SAN infrastructure 
(Fig. 1) provides far better scalability than the in-band accessed virtual SAN (Fig. 8), 
wherein[[,]] the scalability of in-band accessed virtual SAN were severely limited by the 

15 bottlenecked control management station (Fig. 8). 

Storttgc Sharing: 

The present invention also discloses a method of storage sharing mechanism. Once 
the distributed virtual SAN storage pool (1 1 of Fig. 1) is_[[being]] constructed, each IP SAN 
unit[[s]] (4 of Fig. 1) in the pool of distributed virtual SAN mfrastructure (Fig. 1) may [[be]] 

20 hold multiple storage volumes in the form of block dat a, which can be accessed by [[for]] 
one or more hosts (1 of Fig. 1) accessing . Therefore, it [[will]] allows multiple hosts (1 of 
Fig. 1) to share an IP SAN unit (4 of Fig. 1) by granting and assigning each host to 
exclusively access particular volumes on that IP SAN unit (4 of Fig. 1). The Fig. 6 
demonstrates such a storage sharing, wherein[[,]] IP SAN unit (2 of Fig. 6) has three 

25 volumes, which named volume 1 , volume 2, and volume 3. The block data service modules 
(6 of Fig. 1) on DP SAN unit (2 of Fig. 6 ) allows can arrange shar e volume 1 to be accessed 
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exclusively by ffwithll hostl while and shar e s volume 2 to be accessed exclusively by w ife 
host 2 exclusiv e ly . 

Performance; 

With in-band accessed virtual SAN (Fig. 8), the control management station could be 
5 a performance bottleneck. With distributed virtual SAN of this invention^ each host[[s]] (1 of 
Fig. 1) can directly and independently access[[ing]] any IP SAN unit (4 of Fig. 1). 
Therefore, the performance of storage accessing for each host[[s]] will not be affected 
eff e cted and can match the performance of direct attached storage system (Fig, 7) when the 
high speed network connecting media is deployed in the distributed virtual SAN 
10 infrastructure (Fig. 1). 

C e ntralized Managem e nt of Di s tributed Virtual SAN; 

The present invention also illustrates a method of a centralized management of 
distributed virtual SAN. The storage management console on a console host (10 of Fig. 1) 
can communicate with console support software module (8 of Fig. 1) on a.control 

15 management station (3 of Fig. W The storage management console is configured to further 
receive and to furth e r g e t information relating to \\of\] all IP SAN units (4) from control 
management modules (7 of Fig. 1) of control management station (3 of Fig. 1). Therefore, it 
[[can]] provides centralized management functionality for entire distributed virtual SAN 
storage pool (1 1 of Fig. 1), hosts (1 of Fig. 1), and the control management station itself (3 of 

20 Fig. 1). With multiple concurrent tasks controlled by the supporting in console support 
software module (8 of Fig. 1) of control management station (3 of Fig. 1), the storage 
management support console (10 of Fig. 1) can provide a fiill range of system operations and 
tasks. In addition, multiple system tasks and operations can be run concurrently throughout 
the entire distributed virtual SAN and hosts. These management tasks include[[s]] storage 

25 configuration, storage volume allocation and assignment, storage partitio ning and 
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repartitioning, storage, network, and other resource usage and activity activiti es monitoring[[, 
etc.]]. 

Disa s ter Rccovorabiiity: 

In one embodiment, the present invention discloses a process of disaster recovery 
5 capabilities. The use of DNS or may b e other an IP address identification mechanism helps 
this distributed virtual SAN infrastructure to_overcome the geometric (region) limitation^ and 
works well in a [[either]] cross network domain[[s]] environment or in a single network 
domain environment. Therefore, any IP SAN unit or host as well as a^control management 
station could be anywhere on tiie_corporate Intranet, [[on]] department LAN, or [[on]] 
10 Intemet. As a result, the present invention can be used for an emergency or a disaster 

recovery plan because the distributed virtual SAN infrastructure increases logical range by 
100 miles as oppose to the it is possibl e to have a disast e r r e cov e rability plan go e s beyond 
100 mil e s long vs t raditional lO^kilometer limitation. 

In addition, the disaster recovery plan of distributed virtual SAN infrastructure can be 
15 flexibly implemented as showing in Fig. 10. With this recovery plan, the host 1 or 3 (1 of 
Fig. 10) can continue to operate even if [[whenever]] one of its mirrored IP SAN units failed 
(3 of Fig. 10). Also, the spare IP SAN unit can be used to quickly replace the failed IP SAN 
unit whenever there is a.need[[s]]. On the other hand, the hosts (1 of Fig. 10) also can be 
organized into a service pool for providing special services, such as [[for]] distributing video 
20 services, distributed database pool, distributed security monitor services, and all other 

services provided on the net and on or the Web. Therefore, whenever host 1 or 3 failed, the 
spare host can quickly take over their assigned IP SAN storage and replace them to continue 
providing services p rovid e s e rvic e to the end user. 

It should be noted that the storage of any IP SAN unit can be shared and accessed by 
25 multiple hosts. To scale a virtual storage, a host may be assigned to access multiple volumes 
of storage capacities from multiple IP SAN units. In one embodiment, the storage accessing 
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goes directly through communication link between hosts and SAN units, which means that it 
is an out-band access. An advantage of using the present invention is that it has better 
performance and scalability than t hat[rose11 in-band accessed virtual SAN. Furthermore, the 
present invention allows the virtual storage pool to expand dynamically through adding more 
5 IP SAN units into the pool without interrupting systems operation. 

The implementation of web-based multi-concurrent tasks allows entire distributed 
virtual SAN infrastructure to be managed and monitored from a centralized console. Also, 
the IP based distributed virtual SAN infrastructure is a new type of central controlled 
distributed scalable virtual machine (CCDSVMV The software modules used in IP based 
10 distributed virtual SAN infrastructure are web-based operating system models. Furthermore, 
the methods and principles of the IP based distributed virtual SAN storage pool which may 
automatic build and deliver storage services to the end users or clients on-demand bases. The 
present invention can also apply to various data distribution services within the CCDSVM 
infrastructure. 
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